fix(hw_support): Fix crash when reconfiguring flash from 40 to 80 MHz (IDFGH-16831) #17905
Conversation
Reading from the flash while it is being reconfigured leads to data corruption and a crash when the reconfiguration code is located in flash. This is only an issue if a device has a bootloader that runs with 40 MHz flash and an application flashed via OTA that runs with 80 MHz flash. If bootloader and application run with the same flash speed, the reconfiguration is basically a no-op and no data corruption occurs. Fix reconfiguration by placing the code back into IRAM.
|
|
👋 Hello MattiasTF, we appreciate your contribution to this project! 📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more. 🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project. Click to see more instructions ...
Review and merge process you can expect ...
|
github-actions
bot
changed the title
3 participants
7549d08 moved
call_start_cpu0from IRAM to flash. Unfortunately, this included code that reconfigures the flash if the application’s flash speed differs from the bootloader’s flash speed.When an application with a flash speed of 80 MHz is started from a bootloader with a flash speed of 40 MHz, it will crash shortly after
bootloader_flash_cs_timing_config()returns. This is caused by reading instructions from flash while the flash is being reconfigured to the higher speed, which results in corrupt instruction data being read.Possible crashes to encounter:
movi.n a8, 1.As this code runs early during start-up, the device will be stuck in an infinite reboot loop. This means that loading an application built from the 5.5.1 release via OTA onto a device that contains an older bootloader with a slower flash speed will brick the device.
This PR fixes the problem by moving the flash configuration calls into a helper function that is placed in IRAM. The call to increase the flash clock has also been moved so that the GPIO settings and SPI dummy cycles are set to safe values before the clock is increased.
The commit that introduces the problem has already been backported to 5.5.1 as e1faf67, so this fix will also have to be backported.
Note
Moves ESP32 flash config sequence into IRAM helper
configure_flash()and invokes it during early init (when PSRAM HW init is disabled) to avoid executing from flash while reconfiguring.configure_flash()to adjust flash GPIO, dummy cycles, clock, and CS timing safely.bootloader_flash_*calls withconfigure_flash(&fhdr)in early init when!CONFIG_SPIRAM_BOOT_HW_INIT.CONFIG_IDF_TARGET_ESP32; no behavior change for other targets.Written by Cursor Bugbot for commit 7565d53. This will update automatically on new commits. Configure here.